Skip to content

[PAR-778] Bump integration-core to ^5.1.3 and register AdvancedSettings entity#17

Merged
mescalantea merged 5 commits into
masterfrom
feature/PAR-778-bump-integration-core-to-5.1
May 22, 2026
Merged

[PAR-778] Bump integration-core to ^5.1.3 and register AdvancedSettings entity#17
mescalantea merged 5 commits into
masterfrom
feature/PAR-778-bump-integration-core-to-5.1

Conversation

@mescalantea
Copy link
Copy Markdown
Contributor

@mescalantea mescalantea commented May 21, 2026

What is the goal?

Bump sequra/integration-core to the released ^5.1.3 and apply the minimum middleware-side changes needed for v4 → v5.1 compatibility. This unblocks the downstream SeQura Marketing App PAR-778 work, which depends on the v5.1 AuthorizedProxy that forwards merchant id via the Sequra-Merchant-Id header.

References

How is it being implemented?

Net changes against master:

  • composer.json — bump sequra/integration-core from ^4.0 to ^5.1.3.
  • composer.lock — regenerated.
  • src/BootstrapComponent.php — register the new AdvancedSettings DataAccess entity in initRepositories() so the lazy resolution of AdvancedSettingsRepositoryInterface succeeds under v5.1.

No middleware-side merchant-id forwarding code is needed: v5.1.3's AuthorizedProxy sends Sequra-Merchant-Id as an HTTP header, and the downstream Simba PR reads it from there. A transitional MerchantIdAwareStoreIntegrationProxy was added and then removed earlier on this branch once the upstream header contract landed — net diff is zero for that file.

Caveats

  • This is a major bump of a peer library (integration-core 4 → 5.1). Downstream integrators will be forced onto core v5.1 and should cut a corresponding major release of their own.

Does it affect (changes or update) any sensitive data?

No.

How is it tested?

  • Tag-level CI: PHP syntax check + Composer install across supported runtimes.
  • Local: existing test suite passes against the new dependency.
  • End-to-end validated through the downstream SMA PR (#122) against the sandbox merchant portal.

How is it going to be deployed?

  • sequra/integration-core v5.1.3 released
  • composer.json pinned to ^5.1.3
  • Merge this PR
  • Tag a new middleware release (recommend v3.0.0 — major peer-dep bump)
  • Downstream consumers bump to the new tag

🤖 Generated with Claude Code

mescalantea and others added 5 commits May 20, 2026 13:18
Register the new AdvancedSettings DataAccess entity in
BootstrapComponent::initRepositories so the lazy resolution of
AdvancedSettingsRepositoryInterface succeeds under v5.1.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ed-account impersonation

integration-core v5.1.2 sends ConnectionData::merchantId only via the
Sequra-Merchant-Id HTTP header (AuthorizedProxy). Simba's
StoreIntegrationsController reads params[:merchant_id] from the request
body / query string, not from headers, and the shared-account
impersonation path (authorize_merchant_access) returns 403 when the
param is missing. Without this fix, every POST / DELETE from a
service-type api_account fails authorization.

The new MerchantIdAwareStoreIntegrationProxy:
- POST: appends merchant_id to the JSON body root (same level as
  store_integration).
- DELETE: appends merchant_id as a URL query parameter on the resource
  path /store_integrations/<encoded_webhook_url>.
- No-op when merchantId is null/empty, so non-shared-account callers
  see no behavior change.

Registered in BootstrapComponent after parent::initServices() so the
override wins over core's default StoreIntegrationProxy. No core
changes; the body/query placement is a deployment-topology concern of
the shared-account model that every middleware consumer shares.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Simba PR 19469 reads merchant_id from the Sequra-Merchant-Id header that
integration-core's AuthorizedProxy already sends; the body/query injection
is no longer needed.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
… fix branch

Temporary dev-branch reference until sequra/integration-core#60 is
merged and tagged. The "as 5.1.999" alias keeps the dev branch
satisfying the previous "^5.1" semantic so downstream consumers
don't need their own composer.json change to pick this up — only
a composer update.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@mescalantea mescalantea marked this pull request as ready for review May 22, 2026 07:49
@mescalantea mescalantea requested a review from a team as a code owner May 22, 2026 07:49
@mescalantea mescalantea requested review from m1k3lm and removed request for a team May 22, 2026 07:49
@mescalantea mescalantea changed the title [PAR-778] Bump integration-core to ^5.1 and align StoreIntegration transport [PAR-778] Bump integration-core to ^5.1.3 and register AdvancedSettings entity May 22, 2026
@mescalantea mescalantea merged commit 54874e1 into master May 22, 2026
4 checks passed
@mescalantea mescalantea deleted the feature/PAR-778-bump-integration-core-to-5.1 branch May 22, 2026 07:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant